home *** CD-ROM | disk | FTP | other *** search
/ QRZ! Ham Radio 3 / QRZ Ham Radio Callsign Database - Volume 3.iso / digests / tcp / 930191.txt < prev    next >
Internet Message Format  |  1994-06-04  |  14KB

  1. Date: Tue, 27 Jul 93 04:30:05 PDT
  2. From: Advanced Amateur Radio Networking Group <tcp-group@ucsd.edu>
  3. Errors-To: TCP-Group-Errors@UCSD.Edu
  4. Reply-To: TCP-Group@UCSD.Edu
  5. Precedence: Bulk
  6. Subject: TCP-Group Digest V93 #191
  7. To: tcp-group-digest
  8.  
  9.  
  10. TCP-Group Digest            Tue, 27 Jul 93       Volume 93 : Issue  191
  11.  
  12. Today's Topics:
  13.                     convers-ping-pong release 1.18
  14.                          conversd for wampes
  15.                    OS/2 NOS version status and misc
  16.                        sbrk() declaration ????
  17.                       Undelivered mail (2 msgs)
  18.                        Z80 SIO and SCC (2 msgs)
  19.  
  20. Send Replies or notes for publication to: <TCP-Group@UCSD.Edu>.
  21. Subscription requests to <TCP-Group-REQUEST@UCSD.Edu>.
  22. Problems you can't solve otherwise to brian@ucsd.edu.
  23.  
  24. Archives of past issues of the TCP-Group Digest are available
  25. (by FTP only) from UCSD.Edu in directory "mailarchives".
  26.  
  27. We trust that readers are intelligent enough to realize that all text
  28. herein consists of personal comments and does not represent the official
  29. policies or positions of any party.  Your mileage may vary.  So there.
  30. ----------------------------------------------------------------------
  31.  
  32. Date: Mon, 26 Jul 93 11:11:19 CDT
  33. From: andyw@aspen.cray.com (Andy Warner)
  34. Subject: convers-ping-pong release 1.18
  35. To: dc6iq@insu1.etec.uni-karlsruhe.de
  36.  
  37. Fred wrote:
  38. > > [...]
  39. > > from the convers.conf file
  40. > > hostname
  41. > > host host:3600
  42. > > 
  43. > > which will make the Linux kernel (net-2) to make a tcpip connect to the
  44. > > host named in the convers.conf :3600 being the port number..
  45. > > Over slow links via my router (wnos) the conversd program  appears to hand up
  46. > > untill the perm link is established once established any other logins to the
  47. > > conversd works fine...
  48. > This is normal - You should use this to connect via ethernet, not over
  49. > slow links.
  50.  
  51. If the code looks at all like the "vanilla" conversd.c, you can just put
  52. a p->retrytime = 0; after the call to update_permlinks() in
  53. read_configuration(). I think this has the effect of establishing the
  54. permlinks asynchronously. I did this when I couldn't figure out how
  55. else to connect slow permlinks....
  56.  
  57. > [...]
  58.  
  59. I have some users who telnet directly to port 3600 on my
  60. (SunOS based) converse server. It appears that conversd does
  61. not use CRLF to terminate lines - should this be viewed as
  62. a bug in conversd, or should they manually have to tweak their
  63. telnet options ? (tricky call without any definative converse
  64. specification :-))
  65. -- 
  66. andyw. N0REN/G1XRL
  67.  
  68. andyw@aspen.cray.com Andy Warner, Cray Research, Inc. (612) 683-5835
  69.  
  70. ------------------------------
  71.  
  72. Date: Mon, 26 Jul 93 16:49:35 CET
  73. From: BARRY TITMARSH <BTITMARS%ESOC.BITNET@vm.gmd.de>
  74. Subject: conversd for wampes
  75. To: TCP-GROUP <TCP-GROUP@ucsd.edu>,
  76.  
  77. Ok thanks for the infomation on the new version, on the ftp-site.
  78. noted your comments on the host host:socket_number in the convers.conf
  79. the new version works fine even with sym links for the other copies of
  80. the daemon `conversd`
  81.  
  82. Again thanks for takeing the time out to produce it.
  83.  
  84. Barry G8SAU/DC0HK @ various IP's
  85.  
  86. ------------------------------
  87.  
  88. Date: Mon, 26 Jul 93 09:26:20 cst
  89. From: kf5mg@vnet.IBM.COM
  90. Subject: OS/2 NOS version status and misc
  91. To: TCP-Group@UCSD.Edu
  92.  
  93. Tried sending a message to Walt C. asking about NOS and PMAIL for OS/2.
  94. My message got returned as undeliverable. You still out there Walt?
  95. Wondering if you've made any progress on your new versions of tcp/ip for
  96. OS/2. Also wanted to know if the source for PMAIL was available and if
  97. you've played with the Borland, OS/2 compiler.
  98.  
  99. 73's  de  Jack - kf5mg
  100. Internet        -  kf5mg@kf5mg.ampr.org       - 44.28.0.14
  101. AX25net         -  kf5mg@kf5mg.#dfw.tx.usa.na - home (817) 488-4386
  102. Worknet         -  kf5mg@vnet.ibm.com         - work (817) 962-4409
  103.  
  104. ------------------------------
  105.  
  106. Date: Mon, 26 Jul 93 07:31:27 -0700
  107. From: karn@qualcomm.com (Phil Karn)
  108. Subject: sbrk() declaration ????
  109. To: J.R.Jagger@sheffield-hallam.ac.uk
  110.  
  111. I rewrote the grabcore() routine. It now calls DOS's memalloc() routine
  112. instead of sbrk(). You should start with a more recent version of the code
  113. if you want to hack it down, there are a lot of bug fixes there, not just
  114. code growth.
  115.  
  116. Phil
  117.  
  118. ------------------------------
  119.  
  120. Date: Wed, 21 Jul 93 17:15:24 MET
  121. From: MAILER@CSPGUK11.BITNET (Network Mailer)
  122. Subject: Undelivered mail
  123. To: MAILER%CSPGUK11.BITNET@Sdsc.Edu
  124.  
  125.  
  126.  
  127. ----------------------------Original message----------------------------
  128.  
  129.  
  130. ----------------------------Original message----------------------------
  131. Your mail was not delivered to some or all of its
  132. intended recipients for the following reason(s):
  133.  
  134. No such local user: RSCS
  135.  
  136. --------------------RETURNED MAIL FILE--------------------
  137. Received: by CSPGUK11 (Mailer R2.07) id 0957; Wed, 21 Jul 93 17:15:24 MET
  138. Date: Wed, 21 Jul 93 17:02:34 MET
  139. From: Network Mailer <MAILER@CSPGUK11>
  140. Subject: Undelivered mail
  141. To: RSCS@CSPGUK11
  142.  
  143. Your mail was not delivered to some or all of its
  144. intended recipients for the following reason(s):
  145.  
  146. FROM: or SENDER: inconsistent with spool file origin.
  147.  
  148. --------------------RETURNED MAIL FILE--------------------
  149. Received: by CSPGUK11 (Mailer R2.07) id 0222; Wed, 21 Jul 93 17:02:35 MET
  150. Received: from ucsd.edu by Sdsc.Edu (sds.sdsc.edu STMG) via INTERNET;
  151.           Sun, 18 Jul 93 08:21:17 GMT
  152. Received: by ucsd.edu; id AB03154
  153.         sendmail 5.67/UCSD-2.2-sun
  154.         Sat, 17 Jul 93 23:24:29 -0700
  155. Errors-To: tcp-group-relay@ucsd.edu
  156. Sender:   tcp-group-relay%UCSD.EDU@Sdsc.BITnet
  157. Precedence: List
  158. Received: from plains.NoDak.edu by ucsd.edu; id AA03148
  159.         sendmail 5.67/UCSD-2.2-sun via SMTP
  160.         Sat, 17 Jul 93 23:24:27 -0700 for /usr/mail/listhandler tcp-group
  161. Received: by plains.NoDak.edu; Sun, 18 Jul 1993 01:24:25 -0500
  162. From:     ortmann%plains.NoDak.edu%UCSD.EDU@Sdsc.BITnet (Daniel Ortmann)
  163. Message-Id: <199307180624.AA00833@plains.NoDak.edu>
  164. Subject: NOS on MS-Windows?
  165. To:       tcp-group%UCSD.EDU@Sdsc.BITnet (tcp group)
  166. Date: Sun, 18 Jul 93 1:24:24 CDT
  167. X-Mailer: ELM [version 2.3 PL11]
  168.  
  169. 1) Has anyone compiled any of the NOS family on MS-Windows?
  170. 2) Has anyone done it using MS Visual C++??
  171. 3) If it has not been done, then what are your thoughts on the difficulty?
  172.  
  173. --
  174. Daniel "un?X" Ortmann     (talmid)   NDSU Electrical Engineering
  175. ortmann@plains.nodak.edu   shalom    Fargo, North Dakota
  176.  
  177. ------------------------------
  178.  
  179. Date: Wed, 21 Jul 93 17:15:34 MET
  180. From: MAILER@CSPGUK11.BITNET (Network Mailer)
  181. Subject: Undelivered mail
  182. To: MAILER%CSPGUK11.BITNET@Sdsc.Edu
  183.  
  184.  
  185.  
  186. ----------------------------Original message----------------------------
  187. Your mail was not delivered to some or all of its
  188. intended recipients for the following reason(s):
  189.  
  190. No such local user: RSCS
  191.  
  192. --------------------RETURNED MAIL FILE--------------------
  193. Received: by CSPGUK11 (Mailer R2.07) id 0986; Wed, 21 Jul 93 17:15:34 MET
  194. Date: Wed, 21 Jul 93 17:03:00 MET
  195. From: Network Mailer <MAILER@CSPGUK11>
  196. Subject: Undelivered mail
  197. To: RSCS@CSPGUK11
  198.  
  199. Your mail was not delivered to some or all of its
  200. intended recipients for the following reason(s):
  201.  
  202. FROM: or SENDER: inconsistent with spool file origin.
  203.  
  204. --------------------RETURNED MAIL FILE--------------------
  205. Received: by CSPGUK11 (Mailer R2.07) id 0269; Wed, 21 Jul 93 17:03:00 MET
  206. Received: from ucsd.edu by Sdsc.Edu (sds.sdsc.edu STMG) via INTERNET;
  207.           Sat, 17 Jul 93 07:40:24 GMT
  208. Received: by ucsd.edu; id AA13632
  209.         sendmail 5.67/UCSD-2.2-sun
  210.         Fri, 16 Jul 93 22:44:45 -0700
  211. Errors-To: tcp-group-relay@ucsd.edu
  212. Sender:   tcp-group-relay%UCSD.EDU@Sdsc.BITnet
  213. Precedence: List
  214. Received: from SABEA-OC.AF.MIL by ucsd.edu; id AA13618
  215.         sendmail 5.67/UCSD-2.2-sun via SMTP
  216.         Fri, 16 Jul 93 22:44:33 -0700 for /usr/mail/listhandler tcp-group
  217. Received:  by sabea-oc.af.mil (5.59/25-eef)
  218.         id AA26398; Sat, 17 Jul 93 00:41:09 CDT
  219. From:     ssampson%sabea-oc.af.mil%UCSD.EDU@Sdsc.BITnet (Mr. Sampson)
  220. Message-Id: <9307170541.AA26398@sabea-oc.af.mil>
  221. Subject: 9600 Experiances
  222. To:       TCP-Group%UCSD.EDU@Sdsc.BITnet
  223. Date: Sat, 17 Jul 1993 00:41:05 -0500 (CDT)
  224. X-Mailer: ELM [version 2.4 PL13]
  225. Content-Type: text
  226. Content-Length: 1149
  227.  
  228.  
  229. Swinging to the hardware side for a moment...
  230.  
  231. I've recently been experimenting with 2 meter FM 9600 (have a
  232. lot of experiance with a Tekk on 440) and am amazed at how
  233. poorly it performs.  I modified an ICOM 228A both to keep the
  234. receiver on all the time (it shuts it off during transmit as
  235. designed) and the normal VCO and Discriminator taps.  After
  236. discussing it, I'm pretty much convinced that the final IF
  237. filter is the culprit.  I'm using a PacComm TNC which has a
  238. 5 kHz cut-off on its input filter.
  239.  
  240. My theory is that 4800 Hz is the highest modulating frequency,
  241. so the modulation index at 3 kHz deviation would be .625.  Using
  242. a Bessel chart shows +/- 3 sidebands for (6 x 4800) 28.8 kHz
  243. Bandwidth.  I assume the FIR filter on transmit greatly
  244. attenuates the third sideband so we probably only need (4 x
  245. 4800) or 19.2 kHz.
  246.  
  247. The trouble is my ICOM (and most other rigs) has a 455 kHz filter
  248. marked with an 'E'.  PacComm says an 'E' is 15 kHz and a 'D' is
  249. 20 kHz.  I'm not sure what the 10.7 MHz IF has in it.  What's the
  250. general consensus on this?  Do those running 9600 sucessfully change
  251. these out, or is my math all wrong?
  252. ---
  253. Steve N5OWK
  254.  
  255. ------------------------------
  256.  
  257. Date: Mon, 26 Jul 93 12:39:05 BST
  258. From: A.D.S.Benham@bnr.co.uk
  259. Subject: Z80 SIO and SCC
  260. To: TCP-Group@UCSD.Edu
  261.  
  262. I've been trying to sort out a bug in the KISS ROM for the TNC-220, and during the course
  263. of this I've come across something odd with the use of the Z80 SIO and SCC chips.
  264. As the SCC chip (8530) is also used for NOS, I've got the same "problem" with the code
  265. for the SCC driver.
  266. Am I being stupid, or is there really a problem?
  267.  
  268. Both the SCC and SIO chips use a two-stage method to access their internal registers: a
  269. write operation to the control register to specify the internal register to be accessed,
  270. and then a read or write operation to the control register to actually access the register.
  271.  
  272. Now all the code I've been looking at has internal registers being accessed =both= by 
  273. foreground routines and by interrupt routines. This is where I have a problem.
  274.  
  275. Take the following examples:
  276.  
  277. =========================
  278. Foreground Code
  279.  
  280. ...
  281. Write to Control Register, specifying register 4
  282. Read Control Register
  283. ...
  284.  
  285. (This reads register 4)
  286.  
  287. =========================
  288. Interrupt Code
  289.  
  290. ...
  291. Write to Control Register, specifying register 3
  292. Write to Control Register
  293. ...
  294.  
  295. (This writes to register 3)
  296. ===========================
  297.  
  298.  
  299. Now each routine works fine =in isolation=. But what happens if an interrupt occurs whilst
  300. the foreground code is executing the "Write to Control Register, specifying register 4"
  301. instruction?
  302. As I see it, the processor will finish the instruction (so the internal register pointer
  303. is set to point to register 4), and then call the interrupt routine.
  304. The interrupt routine will do the "Write to control Register, specifying register 3"
  305. instruction, except that this will be taken by the chip as a write operation to
  306. register 4. The chip then resets the internal register pointer to point to register 0.
  307. Now the interrupt routine sends the data it thinks it is writing to register 3, except
  308. the chip is expecting a "set register pointer" instruction - so the register pointer
  309. could be set to an unspecified value.
  310. Then the interrupt routine returns, and the foreground routine continues and does the
  311. control register read... except the internal register pointer is probably not pointing
  312. to the right register any more.
  313.  
  314. So, in this example, both the foreground and interrupt routines have executed code which
  315. is not that which was intended (in my experience, this is "a bad idea").
  316.  
  317. I'd have expected that if foreground and background tasks could both access the chip,
  318. then the foreground code would mask interrupts during the two-operation access cycle
  319. (in other words, as the access operation is not atomic, a locking mechanism is needed).
  320.  
  321.  
  322. The Z80 SIO and SCC are at least 10 years old though, and the TNC KISS ROMs don't have
  323. any special coding to get around this problem.
  324. (I was expecting
  325.               Disable Interrupts
  326.               Write to Control Register, specifying register pointer
  327.               Read/Write Control Register
  328.               Enable Interrupts
  329. in the foreground routine. The interrupt routines in the KISS ROMs can't themselves be
  330. interrupted, so they need no additional work).
  331.  
  332. So am I being particularly thick and missed something fundamental? Or is there really
  333. a potential problem lurking in lots of code?
  334.  
  335.  
  336. Andrew Benham
  337. --------------------------------------------------------------------
  338. adsb@bnr.co.uk   BNR Europe Ltd, London Road, Harlow, Essex CM17 9NA
  339. adsb@bnr.ca      +44 279 402372    Fax: +44 279 402029
  340. Home:            g8fsl@g8fsl.ampr.org [44.131.19.195]   G8FSL@GB7HSN
  341. --------------------------------------------------------------------
  342.  
  343. ------------------------------
  344.  
  345. Date: Mon, 26 Jul 93 07:29:47 -0700
  346. From: karn@qualcomm.com (Phil Karn)
  347. Subject: Z80 SIO and SCC
  348. To: A.D.S.Benham@bnr.co.uk
  349.  
  350. I wrap a "disable/restore" sequence around my references to the SCC's
  351. registers. That makes the accesses atomic.
  352.  
  353. Phil
  354.  
  355. ------------------------------
  356.  
  357. End of TCP-Group Digest V93 #191
  358. ******************************
  359. ******************************
  360.